What if we handle that nil? call somehow and give a compile error saying "Calling this method will always return false".

"Calling this method will always return false" implies this method actually exist. But in the macro language, it doesn't need to exist at all.
Now the error message just says undefined macro method 'Type#nil?'. Sure that could be enhanced with something like a recommendation to use == nil instead. But IMO that's not that important. The important part is to fix the bug that nil? doesn't error in the macro language but doesn't work either.

What will be the value of this?

{% puts nil.nil? %}

It doesn't compile. undefined macro method 'NilLiteral#nil?'

Now the error message just says undefined macro method 'Type#nil?'

Oh, I thought this "Now" meant "now before this PR", but it seems to be "in this PR".

I think this is fine then 👍

Just note that if we ever decide to be able to add custom methods to AST nodes in macros, nil? will be a valid method call. And in that case I guess we'd like that to return... maybe true only for the NilLiteral and Nop nodes? Maybe that should be the current behavior?

@asterite I'd suggest not having .nil? return true for Nop nodes. I'd be more in favor of adding a dedicated .nop? method. The main reason being it would be easy to do like ivar.default_value.nil? which would return true for both cases of there being a default with a value of nil and no default at all.

EDIT: Forgot there's actually .has_default_value? so this prob isn't as important as I was thinking.

Oh, yeah, that makes sense. I guess for now we can go with this, and later on change it if needed, still in a backwards compatible way.

While trivial to fix and the .nil? method didn't actually work; this PR was technically a breaking change. Had some code that was doing like !ann[0].nil? that no longer compiles.

I would consider the fact that this code compiled as a compiler bug. It should've always been an error.

Fixing bugs can obviously break code that relied on the bug behaviour, but that shouldn't prevent fixing bugs, right? 😄

In my mind calling .nil? at the macro level should check if the node is a NilLiteral or Nop. I think that's more intuitive.

Yeah, maybe we should add that. It's not strictly necessary though. And I'm not sure about combining NilLiteral and Nop. So this should really be a dedicated feature discussion.

For example, when you do if node in a macro, if the node is NilLiteral or Nop that's considered falsey. So I think nil? would be aligned with that behavior.